【レポート】Alexa Voice Serviceを使用してAlexa音声技術を製品に統合する #reinvent #ALX202

本記事はAWS re:Invent 2017のセッション"ALX202 - "Integrate Alexa voice technology into your product with the Alexa Voice Service"のレポートです。

AWS re:Invent 2017

#Amazon Alexa

#イベントレポート

#ハードウェア

#レポート

#AWS

Yosuke Miyajima

2018.04.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

本記事はAWS re:Invent 2017のセッション"ALX202 - "Integrate Alexa voice technology into your product with the Alexa Voice Service"のレポートです。

このセッションでは、Alexa対応デバイスを開発するためにAmazonが用意したAlexa Voice Service(AVS)という仕組みについての說明と、AVSを使ったデバイス開発を行うためのSDKと開発キットについての說明が、AmazonのPrincipal Solutions ArchitectであるTravis Grizzelさんによって行われました。

導入

音声対話の進化

第1世代
- 単一のマイク
- 常時ON
- スピーカーはどこか別の場所に設置される
- ラジオのように、スピーカーからリスナーへの一方向の話しかけ
第2世代
- プッシュ・トゥ・トーク（Push to talk, PTT）
- ビルトインのスピーカー
- 双方向の通話
第3世代
- 音声アクティベーション
- ノイズキャンセレーション
- プッシュの必要が無い双方向の通話
第4世代
- 360度のマイクカバレッジ
- 複数人の音声検出
- 遠距離の音声検出

Amazon Echo: 最初のAlexa対応機器

Amazon Echoは、

スピーカー
マイク
ネットワークコネクション

を組み合わせただけのシンプルなデバイス

ビジョン：Alexaをあらゆる場所に

現在Alexaは大半がスマートスピーカーの形態で提供されていて、一部スマートフォンでも利用できるような状況だが、サードパーティも巻き込んで、Alexaをあらゆる場所で使えるようにしたい。

Alexa Voice Service (AVS)

AVSとは、

クラウドベースのAlexaの頭脳である。
音声設計をシンプルにし、簡単にデバイスに組み込むことができる
無料で使える（AWS利用費は別）
成長するAlexaのエコシステムを活用することができる
より多くの顧客との接点を持てる

シンプルな音声対話モデル

イベント：デバイスからAVSに送られる情報
ディレクティブ：AVSからデバイスに送られる情報
イベントもディレクティブも、JSONのペイロードとしてやりとりがなされる

基本的な動作

ウェイクワードエンジンがウェイクワード（デフォルトは”Alexa”）を検出すると、ウェイクワードの後に続く音声データストリームがAVSに送信される
デバイスとAVSとのやりとりは、オーケストレーション層となる”スピーチプラットフォーム”を介して行われるスピーチプラットフォームが各種サブシステムの調停を行う
デバイスから”Recognizer”イベントがAVSに送信され、それを受けて音声認識サブシステム(ASR)が生のオーディオファイルをテキストに変換する
ASRが生成したテキストは自然言語理解(NLU)サブシステムに送られて、話者の意図（”インテント”）に変換される
インテントがスキルに渡される
スキルに渡されたインテントへの応答内容のテキストは、TTS(Text to Speech、音声合成)サブシステムへと渡されて、オーディオファイルへと変換されて、デバイスに送信される。デバイスは単にそのオーディオファイルを再生するだけでよい

タイマーをセットする際のイベントとディレクティブのやりとりの例

ユーザーが「アレクサ、10分のタイマーをセットして」と発話すると、発話内容の音声データと共に、”recognizer”イベントがAVSに送信される
Recognizerイベントと音声データを受け取ったAVS側では、オーケストレーション層がASR、NLU、Skill、TTSなどのサブシステムを制御して、最終的に「10分のタイマーをスタートします」という音声データと共に”speak”ディレクティブがユーザー（デバイス）に送信される。発話内容はMP3フォーマットの音声データとしてデバイスに送信される
Speechディレクティブの発話内容の発話が始まるとただちに”speech started”イベントがデバイスからAlexaに対して送信される
デバイスの発話が完了するとspeech finished eventがAVSに送信される。それと同時にAVSコントローラーがオーディオプレイヤーでspeakディレクティブで受け取ったMP3を再生する
Set alertディレクティブがAVSからデバイスに送信されて、Alert Manager storeに保存される
10分後、Alert StartedイベントがデバイスからAVSに送信されて、実際にアラートが鳴り出す

デバイスとAVSとの情報交換

イベントとディレクティブのやりとりはHTTP/2の持続的接続を用いてAVSとデバイス間で行われる
AVS側からの通知やメッセージを受け取れるように、最初にダウンストリームチャネルを確立する必要がある

AVSデバイスSDK

製品レベルのデバイス開発に対応
C++で開発されたライブラリ
- オーディオ入力の処理
- AVSとの恒常的な接続の確立
- デバイスとAlexaで行われる全てのインタラクションの処理

AVSデバイスSDKの主要な構成要素

Audio Input Processor (AIP)
Wake Word Engine
Alexa Communications Library (ACL)
Alexa Directive Sequencer Library (ADSL)
Capability Agents
Activity Focus Manager Library (AFML)

オーディオのキャプチャから処理まで

Shared Data Stream
- 単純なリングバッファ
- オーディオデータを継続的に取り込む、使われないデータは廃棄される
- デバイスのメモリにオーディオデータが格納される
Wake Word Engine
- Shared Data Streamに取り込まれるオーディオデータに対して、デバイス上にある”Alexa”という単語モデルと一致するかどうかの検査を常時行う
- 一致を検出したら、AIPにトリガーを送る
Audio Input Processor
- トリガーを受けた時のみオーディオデータをAVSに送る
- AVSから“stop directive”を受け取るまでオーディオデータをAVSに送る

AVSとの情報交換

ACLは恒常的なダウンチャネルのストリームを確立する
双方向のイベントストリームをオープンしてクローズする
ACL(Alexa Communication Library)はディレクティブをADSL(Alexa Directive Sequencer Library)に転送する

命令の伝達

ACLからディレクティブを受け取る
ディレクティブを適切な順序で処理する
ディレクティブを適切なCapability Agentに転送する

ユーザーとの対話の優先順位付け

AFML(Alexa Focus Manager Library)が、ある時点においてどのcapability agentが優先されるのかを制御する　

特定の機能の実行

機能毎に用意されたCapability Agentが担当する

Capability Agent	機能
Speech Recognizer	スピーチのキャプチャ
Speech Synthesizer	スピーチの合成
Alerts	時刻とアラートの管理
Audio Player	音楽再生の制御
Speaker	ボリューム制御、ミュートなど
Notifications	通知機能
System	AVSとのステータス通信
PlaybackController	ボタンによる楽曲の開始・停止・スキップ
TemplateRuntime	視覚メタデータをレンダリング

AVSデバイスSDKとAVSの相互作用

AVSデバイスSDKの特徴

移植性が高い
- Linux、Mac OS、ラズベリーパイ向けのSDKを用意
- さまざまなハードウェアプラットフォームへ対応可能
- ガーミンの例
  - Alexa対応製品を素早く事情に投入するために、AndroidOS向けにAVSデバイスSDKをクロスコンパイルした
拡張性が高い
- 新機能を最小限のグルーコードで追加可能
- Hisense社は、自社製品のAlexa対応TV向けに独自のカードを表示させたかったので、独自のcapability agentを書いた
モジュラー構造
- 必要なライブラリだけを使い、必要ないものは除外できる
- 好きなWWE(ウェイクワードエンジン)を選ぶことができる
- Sonosは自社開発のAlexa対応製品に独自のメディアプレーヤを搭載した
アクセシブル
- SDKのC++コードはGithub上で公開
- 製品独自のUXのためにSDKの振る舞いを変更可能

AVSデバイスSDKサンプルアプリを用いたプロトタイピング

サンプルアプリはgithub上で公開されている
商用グレードのSoC(NXPなど)またはラズベリーパイでの開発に対応
「アレクサ」という単語でウェイクするウェイクワードエンジンが同梱

ハードウェア開発について

Alexa対応機器を開発する場合、ハードウェアの開発からまずとりかかること。ハードウェアの開発には１２ヶ月以上かかる。一方、SDKの実装については通常２〜３ヶ月、早い場合は２〜３週間で完了する

Alexaの製品への組み込み

最も簡単な方法は、既存のAlexa対応製品をはめ込むこと
- iHomeクロックライトや、オリジンアコースティックのシーリングマウントなどがこの方法で製品を開発
一般的には、リファレンス・デザインを用いたデバイス開発を行う

リファレンス・デザイン

ホワイトボックスデザイン
- 機能・外装が決まっている
- 外装の色を変えたり、ロゴをつけたり程度はできる（それ以上のことはできない）
- Gemtek社のPuckなど
フォームファクターリファレンス・デザイン
- ホワイトボックスデザインよりもカスタマイズ性がある
- SDカードポート、HDMIポートの追加など可能
- 内部のハードウェアもある程度カスタマイズできる場合もある
- Gemtek社のVita FFRDなど
AVSイネーブルドモジュール
- フォームファクター自体からカスタマイズしたい場合はAVSシステムインテグレータが提供するAVSイネーブルモジュールを使う
開発キット
- カスタム性の高い製品を開発したい場合は、開発キットを使う

音声モデル

Touch Activated
- プッシュ＆ホールド型
  - Fire TV用のAlexa対応リモコンのような、ボタンをプッシュ＆ホールドしている間に話した内容がAVSに送信されるもの
- タップトゥトーク型
  - Amazon TapやAmazon Echoについているアクションボタンのような、ボタンをタップするとAVSに音声の送信が開始されるもの。発話の終了検出はクラウド側で行われる
- いずれのタイプもwake wordを発する必要無し
Hands-Free Voice Activated
- wake word検出によるハンズフリーアクティベーション
- 5~7フィートくらいまでの距離での利用を想定
- デバイスに向かって話しかけるイメージ
Far-Field Voice Activated
- Amazon Echoのように、デバイスから離れた場所からでも音声で操作可能

AVSクライアントのハードウェア構成

マイクアレイボード
- マイク
- ADC(ADコンバータ)
DSPボード
- DSP(Digital Signal Processor)
  - ノイズキャンセレーション、AECなどのオーディオアルゴリズムの実行
- DAC(DAコンバータ)
  - DSPからのオーディオ出力をアンプにつなぐ
SoCボード
- SoC(System-on-a-Chip)
  - WWE(Wake word engine)
  - AVSクライアント
  - オーディオドライバ
- WiFiインタフェース

オーディオフロントエンドの構成要素

オーディオアルゴリズム
マイクの数
マイクの配置

作ろうとするデバイス毎に検討する必要がある

オーディオアルゴリズム

ウェイクワードエンジン

ウェイクワードエンジン(Wake word engine,WWE)は、”Alexa”という単語を識別して、音声のクラウドへの送信を開始する

一般的にSoC上で実行される
モデルサイズは一般的に大きいほど精度が良い
クラウドベースの検証が併用される
- AVSクラウド側でデバイス（クライアント）側のWWEの識別結果をダブルチェックする

ノイズリダクション

Alexaに話しかけようとする話者の声以外の全ての音は雑音になる
- 雑音が多ければ多いほどAlexaの応答の精度は低下する
Far-Field型はHands-Free型が全く応答できないようなSNR(SN比,信号と雑音の比率)が低い環境下でもある程度の精度で応答できる
高いSNR環境下ではHands-Free型でもFar-Field型でも大差なく高い精度で応答できる

アコースティックエコーキャンセレーション

反響を相殺してSNRを向上させるためにオーディオフィードバックを行う
オーディオフィードバック
- 音楽のオーディオデータはスピーカーに送られると同時にDSPにも送られてマイクからの入力データから減算される

ビームフォーミング

最初に音声が到達したマイクと最後に音声が到達したマイクの組み合わせから、話者の方向を推定する話者に近い方のマイクのゲインを上げる

ビームフォーミングにおけるデバイスの設置方向について

ビームフォーミングを行う際、デバイスの設置位置も考慮に入れる必要がある
- EchoやEcho Dotの場合は、テーブルの上のような平面にデバイスの上面を天井に向けて置いて使われることを想定してチューニングされており、天井や壁に設置とりつけた場合はビームフォーミングが適切に機能しない。静かな環境下では動くかもしれないが、騒音があると全然使えなくなる

マイクの配置について

テーブルトップ型（Echo、Echo Dotなど）
- 円状に配置
壁掛け型
- 水平に一直線に配置

マイクの数

Touch Activated型: １つで十分
Hands-Free型：ノイズリダクションとユーザーの位置を特定するために最低２つ必要
Far−Field型：一般的に4,6,7,8個かそれ以上必要

マイクの数が多いほど応答精度は良くなるが、数を2倍にしたからといって2倍の効果があるわけではない
SNRの高い環境では少ないマイクでも高い応答精度が得られる
SNRが低下するとマイクが7つあっても応答精度は低下する

AVS開発キット

高性能なボイスキャプチャー機能の統合
マイクアレイ、DSP、SoCを含む開発キット
先進的なチップセットプロバイダによるサポート

公式Webにさまざまなタイプのキットの情報がある

Alexa対応デバイス開発に取り組む際の留意事項

ユニークなものを作る
- 単にAmazon Echoや他社製のスマートスピーカーの類似品を作ろうとしない
UXファーストで考える
- ユーザーに製品をどのように使って欲しいのか、実際のユースケースを考える
デバイスの用途によっては、マイクはたくさん無くても大丈夫な場合もある
元々Alexaを組み込む予定の無かったデバイスにAlexaを搭載しようとすると、搭載のためだけに12ヶ月間の追加工期が必要になる場合がある
- こういう場合は、次のモデルから、最初からAlexaを搭載することを考慮した設計を行うほうがよい
AVS開発キットを使って開発をはじめる
- 開発キットは認証を通すノウハウを持っているメーカーが開発しているので、適切に使えば認証を通すまでの労力を削減することができる
AVSデバイスSDKを活用する
- 　Alexaにはこれからも新しい機能が追加されていくので、SDKもそれに追随して更新される
デバイス開発に十分な時間を確保して取り組む
- Alexaを製品に搭載するために、だいたい２〜１２ヶ月、長いときには１８ヶ月くらいを要することがある
Alexaに追加される新しい機能のためにCPUパワー・RAMなどのリソースに余裕をもたせる
AVS認証に備える
何かあったらAmazonのAVSチームに相談する
AVSのSolution Integratorもいるので、必要に応じて活用する